1. Field of the Invention
The present invention relates to the field of internetwork operating system software. More specifically, the present invention relates to a RAM-based directory of a flash file system located in a software layer in an internetwork operating system.
2. The Background
An internetwork operating system (IOS), normally as software, provides a common functionality, scalability, and security for most or all devices on a network. It allows for the centralized, integrated, and automated installation and management of internetworks, while ensuring support for a wide variety of protocols, media, services, and platforms.
Devices that run IOS may have internal Flash or Personal Computer Memory Card International Association (PCMIA) slots that can hold flash cards. A flash card is a card containing memory that holds its content without power. Throughout this application, the term xe2x80x9cflash cardxe2x80x9d is used, but one of ordinary skill in the art will recognize that other types of non-volatile memory may be used instead of flash cards, including Electrically Erasable Programmable Read Only Memories (EEPROMs), and other firmware chips. In IOS, generally executable images or configuration in files regarding the device are stored on these flash cards.
Obviously, when files are stored in a memory, there must be a mechanism for retrieving the files. Typical IOS software provides a minimal or no directory for such files stored in flash card on a device. FIG. 1 is a block diagram illustrating flash cards in a typical device. Device 10 may have PCMIA slots 12, 14 (hereinafter called xe2x80x9cslot axe2x80x9d, and xe2x80x9cslot bxe2x80x9d, respectively). Flash cards 16, 18 may be inserted into PCMIA slots 12, 14, respectively. The typical IOS software will have no independent directory for files stored on any of these flash cards.
FIG. 2 is a diagram illustrating a flash card and flash card accessing module as typically used in IOS software. Flash card 50 may reside in a PCMIA or similar slot in the device. Flash card 50 may contain a data structure 52 (here termed fslib_device_info_block), which contains information on the format, size, and other attributes of the flash card. Additionally, flash card 50 may contain multiple files 54, each residing in addresses which can be measured by the offset 56 from the beginning of the flash card. A flash driver 58, may reside on the device or otherwise separated from the card and contain information regarding how to access the flash card.
Accessing a file stored on the card in a slot may be performed by providing the slot name and file name to the IOS. For example, a request for a file named xe2x80x9cfile2xe2x80x9d in the card located in slot b of a device may be presented to the IOS in the form xe2x80x9cslot_b:file2xe2x80x9d. IOS software may then reference the flash driver 58 corresponding to the card in slot b, and request information on the offset for file 2. In the illustration in FIG. 2, the offset would be returned as xe2x80x9c3xe2x80x9d. Then the IOS could access the flash card, providing an offset of 3 to find the location of file 2. File 2 could then be read. The file may itself contain a header and a data portion, with the header containing fields set aside for the name of the file, size of the file, and other attributes.
This type of directory structure (it is referred to as a directory structure even though it arguably contains no directories at all) suffers from many drawbacks. First, it lacks the ability to have a true directory structure (with directories and subdirectories) forming a xe2x80x9ctreexe2x80x9d type hierarchical structure. Additionally, the xe2x80x9cdirectoryxe2x80x9d is limited in that the name for slot a must always be xe2x80x9cslot_axe2x80x9d. There is not an opportunity to have a different, more creative, or more efficient name for the directories.
Perhaps the biggest drawback, however, of the typical flash file system is evident when one attempts to use it with a more advanced IOS software. IOS software has been evolving quickly. It is now possible to have IOS software be modular, where any component, such as a software module, can be swapped out and replaced without causing an interruption in the entire system (for example, where an old module is replaced with a newer one). For this to occur, it is necessary to have flexible storage of files on Flash cards in a hierarchical format, so that what is old and what is new can be organized in many levels of complexity. Without modification or additional components, the xe2x80x9cdirectoryxe2x80x9d structure outlined above would not work with such a modular system.
What is needed is a flash file system that may be used with modular IOS software.
A flash file system for use with flash cards and internetwork operating system software is provided. Absolute path names are stored in the name field of existing files on flash cards. When the system is initialized, a directory structure is created and stored in RAM by accessing the absolute path names stored in the name field of each file on the flash cards. Accessing a file on a flash card is then accomplished by traversing the directory structure in RAM, and going directly to the precise location of the file on the flash card, thereby minimizing the amount of information that must be retrieved from the flash cards and greatly increasing the speed of accesses. Additionally, cards designed for use with older, non-modular internetwork operating systems may still be used, as name fields for files in these flash cards may easily be used to store absolute path names.